Programming environments and “virtual machines,” including C, C++, C#, CLR (Common Language Runtime), Java, VB.NET, and so forth) typically present types of variables, including value types and reference types. Value types are variables that contain a value for an object. Value types are of fixed size, often allocated on the stack, and when passed between functions are copied in their entirety. However, there are significant restrictions on their use. For example, a subclass cannot be derived from a value type in some programming environments, and in any environment, a value-type cannot be treated polymorphically.
Reference types are variables in which the variable does not actually contain an object's bits, but rather contains a reference to the object's bits. Reference types are heap allocated, passed between function by passing pointers to the objects, and (at least in contemporary, dynamic programming environments) their memory is automatically managed through garbage collection.
For many programming APIs (application programming interfaces) that use reference types, it is very useful and efficient to be able to treat variables sent into them as immutable (or non-modifiable), and have the API make a copy of the variable when it is being sent into the API. The danger of not doing so is that any change to the variable that was sent into the API results in changes to its use, and those changes are often undesirable and cannot be handled appropriately. Note that value types do not have this problem, since value types are always copied on use.
However, programmers do not like the immutability requirement, and previous attempts to provide some mutable-like behavior have not been well received. By way of example, consider a graphics scene designer specifying via an API call that an object's (e.g., a button's) color is to appear red. To change the color at a later time, the designer needs to create a new object with the new color and replace the old object with it, because the old object is immutable. To this end, U.S. patent application Ser. No. 10/402,268, now U.S. Pat. No. 7,126,606, assigned to the assignee of the present invention and hereby incorporated by reference, describes a system and method in which resource objects in the system may utilize a builder pattern. In the builder pattern, immutable objects are created with a builder class, which is a companion class that is effectively mutable. The designer creates an immutable object to mirror the parameters set on the builder, creates a new builder for that object, and initializes it from the immutable object. The designer then changes the builder as necessary. Once done, the designer can build a new object, by changing the builder and reusing it to create another immutable object.
Although this solution works well, programmers do not like having to deal with the builder pattern, which requires use of a dual set of types. Moreover, programmers do not like the concept of immutability in general. Note that with immutable approaches, programmers are fundamentally unable to make changes deep in an object, which is a significant drawback. With the builder pattern or other approaches that maintain immutability, making a deep copy of the object, modifying it, and setting it back in is not very performant. As APIs and object models for more modern programming environments like the CLR and other contemporary APIs become more relevant, the drawbacks associated with such immutability become more significant.